Many businesses are providing access to their products and services through applications that are delivered over computer networks such as the Internet. These applications typically have a multi-tiered architecture. In those cases where the applications are delivered over the Internet they are commonly referred to as Web-based applications. FIG. 1 is a block diagram of a Web-based application 100 having a multi-tiered architecture.
Web-based application 100 includes client layer 110, application layer 120, and database layer 130. Client layer 110 includes user interface 112 that runs on a client computing device such as a desktop computer, laptop computer, personal digital assistant, telephone, and the like. In a Web-based environment, user interface 112 is typically a Web browser. User interface 112 may collect input from a user and provide that input to application layer 120 for processing.
Application layer 120 includes application server 122 to receive and process input from client layer 110. Application server 122 typically includes a number of subcomponents including, for example, connectivity layer 140, presentation logic 142, business logic 144, and database interface 146. Connectivity layer 140 provides connections to client layer 110 using protocols such as the HyperText Transfer Protocol (HTTP), HTTP secured through the Secure Socket Layer, the Simple Object Access Protocol (SOAP), and the like. Presentation logic 142 generates a Graphical User Interface (GUI) using, for example, a markup language such as the Hyper Text Markup Language (HTML). Business logic 144 represents the core of the application, for example, the rules governing the underlying business process (or other functionality) provided by the application. Database interface layer 146 provides an interface to database layer 130. The Java 2 Enterprise Edition Specification v1.3, published on Jul. 27, 2001 (the J2EE Standard) defines an increasingly popular architecture for application layer 120.
Database layer 130 includes data access logic used by business logic 144 to store and retrieve data in database 132. Database 132 provides non-volatile storage (sometimes referred to as a persistent store) for the data accessed and/or processed by application layer 120. Database 132 may be, for example, a relational database or an object-oriented database.
In some cases, business logic 144 may be implemented with Enterprise Java Beans (EJBs). EJBs are server-side J2EE components that provide business logic and represent persistent data. Although EJBs provide a flexible architecture for business logic 144, they also introduce a certain amount of complexity.
FIG. 2 is a block diagram of distributed system 200 illustrating some of the complexity of implementing business logic 210 with EJBs 211-216. EJBs 211-216 are developed from an objected-oriented point-of-view. That is, objects are typically accessed by identifying a first object as a starting point and finding additional objects by, for example, following references or calling methods. In contrast, database 220 is typically organized according to a completely different organizational model that is based on set-oriented query and update statements.
Conventional mapping architecture 230 attempts to map the object-oriented domain of business logic 210 to the relational domain of database 220. Conventional mapping architecture 230 is typically only able to process a limited set of the queries that are generated by business logic 210. In addition, conventional mapping architecture 230 is typically constrained to interoperating with a database provided by a particular vendor. Conventional mapping architecture 230 typically lacks the capacity to perform a variety of validity and compatibility checks on the metadata and schemas defining various aspects of the architecture.